A telecommunications network or group of networks are made up of many devices and components that collectively communicate data from a desired starting point to a termination point. A common network element is a telecommunications switch. A switch, or switching system, can take the form of a mechanical, electrical, or electronic device that opens or closes circuits, completes or breaks electrical paths, or selects paths or circuits upon which to communicate data. Switches can be used in connection with a circuit-based network or a packet-based network.
For data to be routed correctly, correct translation (alternatively “translations”) information must be in place. The act of “translation” refers to the interpretation by a switching system of all or part of a destination code to determine the routing of call or data traffic. “Translation information” refers to information related to routing data through a communications network. If translations data is wrong, a variety of problems can occur, not limited to calls dropped, data lost, busy signals, and other types of service interruptions.
Ensuring that correct translation information is present in a communications network is a task persistently pursued by telecommunications carriers. Currently, however, verifying translation information is a difficult, time-consuming, and expensive task. Translations analysts enter translations requests. A translations request is a request to modify translation information. If a new area code is introduced into a system, for example, then analysts will submit translations requests to modify translation information so that calls will be routed properly. But because verifying translation information is a cumbersome task, a telecommunications carrier may simply not verify that the translations request was entered correctly. Some carriers may opt to manually verify translation information, but will do so at lengthy intervals because of the resource-intensive nature of processing the data associated with verifying translation information. Translation information can be gathered by submitting a translation-verification command.
A translation-verification (“traver”) command can be submitted to receive back translation information. Table I illustrates a series of traver commands and data sets that are respectively returned incident to each command.
TABLE ICommand Line Traver Results>traver 1 5412983439 2984567 ntDIGIT TRANSLATION ROUTES1 LINE5412984567STTREATMENT ROUTES. TREATMENT IS: GNCT1 NCAANN2 T1203 LKOUT+++ TRAVER: SUCCESSFUL CALL TRACE +++>traver 1 5412983439 411 ntDIGIT TRANSLATION ROUTES1 PTLDOR131GTO411ST2PTREATMENT ROUTES. TREATMENT IS: GNCT1 NCAANN2 T1203 LKOUT+++ TRAVER: SUCCESSFUL CALL TRACE +++>traver 1 5412983439 511 ntTREATMENT ROUTES. TREATMENT IS: VACT1 VCAANN2 T1203 LKOUT+++ TRAVER: SUCCESSFUL CALL TRACE +++>traver 1 5412983439 911 ntDIGIT TRANSLATION ROUTES1 VFG: THD911911STTREATMENT ROUTES. TREATMENT IS: GNCT1 NCAANN2 T1203 LKOUT+++ TRAVER: SUCCESSFUL CALL TRACE +++...>traver 1 5412983439 101022219137917000 ntDIGIT TRANSLATION ROUTES1 PTLDORWA3MD9137917000ST2 PTLDORWA3MD29137917000ST3 EAPEG4 NCAANNTREATMENT ROUTES. TREATMENT IS: GNCT1 NCAANN2 T1203 LKOUT+++ TRAVER: SUCCESSFUL CALL TRACE +++>traver 1 5412983439 101028819137917000 ntDIGIT TRANSLATION ROUTES1 PTLDOR62AMD69137917000ST2 PTLDOR62AMD29137917000ST3 EAPEG4 NCAANNTREATMENT ROUTES. TREATMENT IS: GNCT1 NCAANN2 T1203 LKOUT+++ TRAVER: SUCCESSFUL CALL TRACE +++>traver 1 5412983439 101033319137917000 ntDIGIT TRANSLATION ROUTES1 UTC77PH9137917000ST2 UTC77AF9137917000ST3 EAPEG4 NCAANNTREATMENT ROUTES. TREATMENT IS: GNCT1 NCAANN2 T1203 LKOUT...
An exemplary syntax follows for a traver command (as implemented in an illustrative switch, the DMS100 switch offered by the Nortel Networks Corporation of Brampton, Ontario): : “traver L initiation point| |destination point|NT.” The first parameter “L” refers to “line,” but could also be “tr” for “trunk” or “v” for “virtual trunk.” The second parameter, |initiation point|, can be an originating phone number or other origination address. The third parameter, |destination|, can be a destination phone number or some other target address. Finally, the last parameter “NT” represents a mode that corresponds to an amount of data returned incident to issuing the traver command. Alternatives include a “t” for “table mode”—which returns table data—or “nt” for “no tables”—which does not return table data.
As can be seen from Table I, the data returned incident to submitting multiple traver commands (manually, one after another) appears in a format that is difficult to read. If an analyst were charged with the task of confirming that the data in Table I reflects accurate translation information, then he or she would have to laboriously peruse through each line item and compare the line item against some other data set that is hopefully correct. Such a process lends itself to human error. The prior art does not offer an efficient method to verify whether current translation information is correct or whether a translation analyst's routing schemes are working correctly.
More data items than only those shown in Table I can, and often are, be returned to verify whether calls are routed correctly based on translation information. Typically, a trunk-group order is returned. An exemplary trunk-group order includes primary high, intermediate high, direct final, and ultra final. This trunk-group order corresponds to a primary route, secondary route, tertiary route, and final route. The data returned displays what trunk groups are being hit upon while data is attempting to arrive at a desired termination point. Absent the present invention, the results returned must be manually analyzed line by line, character by character. Shortcomings of the prior art are particularly visible when an outage occurs.
If some event, such as a natural phenomenon or human error, results in a service outage, then customers will be out of service until the problem is fixed. To the extent translation data is compromised, new translation data must be populated in the correct switch elements. A paramount step in the process to reestablishing service is to verify that translation information is the same as what it was prior to the outage.
A prior-art process for verifying data would involve an analyst typing in one traver command, reading each line and character of data returned, and verifying that the data returned is the same as it was prior to the outage. Such a process can consume a great deal of time, from several hours to possibly days. Meanwhile, data communications would be interrupted for the duration of the outage: emergency calls would not get through, individuals would not be able to place phone calls, access to networks such as the Internet would be disrupted, and a litany of other problems would stem from such an outage. The translations analyst must be trained to be able to interpret the data returned from issuing the traver commands.
If a network-translations analyst implemented a translations-change request, then good practice would be to verify that the new translation information corresponds to the desired change. But because issuing a traver command and then comparing the results to potentially out-dated values is a time-consuming process, such verification is often simply not made.
Absent the present invention, a carrier is often relegated to learning about translations errors from its customers. That is, when bad translation information exists in a switch, the error may not be discovered until a customer attempts to dial a phone number or otherwise communicate data traffic that relies on the correctness of the translation information. In particularly bad situations, a user's service may be so interrupted that he or she may not even be able to contact the carrier to notify them of the error. In such situations, the user may have to bear additional inconvenience of notifying the carrier from a different location.
The current state of the art could be improved by providing a method and system that allows current translation information to be compared against a defined benchmark efficiently. Moreover, a method and system are needed to allow multiple verification commands to be run in batch and have the data returned be automatically compared against benchmark data to identify any mismatches.